home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 691 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.0 KB
  1. From: mk@anuurn.do.open.de (Martin Koehling)
  2. Subject: Re: (another) problem with mntlib41 tfork() function
  3. Date: Mon, 06 Dec 1993 22:06:48 MEZ
  4. Mime-Version: 1.0
  5.  
  6. >Hi!
  7.  
  8. Hi, too!
  9.  
  10. > It was quite often mentioned that the mintlibs tfork() function shouldn't
  11. >be regarded as anything more than a hack until MiNT gets a real vfork() call,
  12. >so I know I should use it with caution, but today I've strumbled into a
  13. >really severe problem when writing a multi-threaded smtp sendmail clone.
  14. >
  15. > It goes like this: Each time a thread is started, memory is allocated from
  16. >the calling process via pexec(5) to create a new basepage. Since this base-
  17. >page isn't immediately started, the memory seems to be assigned to the
  18. >calling process. This one of course forgets the adress of the threads basepage
  19. >as soon as the tfork() call is left.
  20. >
  21. > So the thread comes up, works a bit and goes down again, leaving the basepage
  22. >memory assigned to the caller, who doesn't know about this and therefore won't
  23. >free it. To be more precicly: Each thread costs me 16K (memprot) which are lost
  24. >forever.
  25. [...]
  26. >Mightn't it be a good idea to perhaps add some Pexec() mode which does
  27. >the same as the thread code from the library, but really assigns all child
  28. >memory to the child, so Pterm() can free it?
  29.  
  30. Please try the following patch to MiNT 1.09:
  31.  
  32. *** o:\dosmem.c    Wed Aug 18 20:16:18 1993
  33. --- dosmem.c    Mon Dec  6 21:32:34 1993
  34. ***************
  35. *** 586,605 ****
  36. --- 586,616 ----
  37.        * if we didn't call fork_proc then we're overlaying.
  38.        * NOTE: after this call, we may not be able to access the
  39.        * original address space that the Pexec was taking place in
  40.        * (if this is an overlaid Pexec, we just freed that memory).
  41.        */
  42.           (void)exec_region(p, base, thread);
  43.           attach_region(p, env);
  44.           attach_region(p, base);
  45.           if (text) attach_region(p, text);
  46.  
  47. +         if ( mode == 104 )
  48. +         {
  49. +         /*
  50. +         * Cause basepage and environment to be owned *only* by the
  51. +         * child, not by both child and parent; when the child
  52. +         * terminates, base and env are freed automagically...
  53. +         */
  54. +             detach_region(curproc, base);
  55. +             detach_region(curproc, env);
  56. +         }
  57. +
  58.           if (mkname) {
  59.       /* interesting coincidence -- if a process needs a name, it usually
  60.        * needs to have its domain reset to DOM_TOS. Doing it this way
  61.        * (instead of doing it in exec_region) means that Pexec(4,...)
  62.        * can be used to create new threads of execution which retain
  63.        * the same domain.
  64.        */
  65.               if (!thread)
  66.                   p->domain = DOM_TOS;
  67. ~~~~~~(snip)~~~~~~~~
  68. This shouldn't cause any compatibilty problems, but I didn't really test
  69. it...
  70.  
  71. > But I feel something like there isn't something like real child memory, so
  72. >all memory the child may at any time allocate, is also shared by its parent.
  73.  
  74. I don't think so - as far as I can see, Pexec(104) "duplicates" all memory
  75. owned by the parent _at this moment_, and any memory allocated by child or
  76. parent after this point is owned _only_ by the allocating process.
  77.  
  78. -- 
  79.  Martin Koehling | mk@anuurn.do.open.de | Martin_Koehling@un.maus.ruhr.de
  80.